PATHMac OS 8 Developer Documentation > Operating System Services > Multiprocessing Services >

Adding Multitasking Capability to Applications Using Multiprocessing Services

   

Criteria for Creating Tasks

Although you can in theory designate almost any type of code as a task, in practice you should use the following guidelines to make best use of the available processors and to avoid unnecessary bottlenecks.

• Tasks should generally perform faceless, calculation-intensive processing.
• The work performed by a task should be substantially more than the time required to process the request and result notifications. If it takes much longer to notify a task and retrieve results than to execute the task itself, an application's performance will be dramatically worse with multiprocessing. Assuming a typical intertask signaling time is 20-50 microseconds, your tasks should take at least 200-500 microseconds to execute. If you want to explicitly calculate the intertask signaling time, you can use the sample code provided in Calculating the Intertask Signaling Time .
• If your task needs to allocate memory, you must allocate the memory prior to signaling the task, or use the function MPAllocateAligned .
• Tasks should not call 68K code. The 68K emulator runs only cooperatively within the Mac OS task, and not within any preemptive task. If you must call 68K code, you can do so using a remote procedure call. See Making Remote Procedure Calls for more information.
• Tasks should not call Mac OS system software functions except through remote procedure calls. See Making Remote Procedure Calls for more information.
• Tasks should not access low-memory global data. A task may be executing at any time, including when applications that did not create them are running.
• Tasks should not call into unknown code. If you allow third parties to specify a callback function, you should never call that function from a task, since you cannot control what the callback will do. Calling back into nonreentrant code could easily corrupt data or cause a system crash.
• Avoid global variables. The main cause of nonreentrancy is the manipulation of global data. Tasks that manipulate global variables, global states, or buffers pointed to by global variables must use synchronization techniques to prevent other tasks from attempting to do so at the same time. Read-only global data are allowed.
• Do not call any Multiprocessing Services functions at interrupt time unless you are signaling a notification mechanism. See Notifying Tasks at Interrupt Time for more information.